Event Management

This section gives ideas for how to use the Event Manager component with Service Desk.

Using Event Manager for Comprehensive Event Management

Event Manager enables you to configure external systems to create, progress and resolve/close Event processes in Service Desk. This section highlights best practice and gives design ideas for some key concepts.

See Ivanti Event Manager for more information about the configuration and usage of Event Manager.

Any tool that can generate a URL, a command line, or a batch file (with parameters that identify the type of event and the CI affected) can interact with Event Manager. Typically, these are monitoring tools that can send alerts (for example, by e-mail, text message, URL, or custom executable) when an alert is required.

However, do not configure Service Desk to respond to every alert that a monitoring system generates: use Event Manager for significant alerts only. Event Manager is not itself a monitoring tool, but is a consolidation point where significant alerts can be converted using Event processes.

Event Manager can receive alerts from many different sources, and can map different sources to different Event processes – remember that you can use many different processes with Event Manager. For example, you could configure a Major Event process and a Standard Event process. It is not practical to monitor everything to a detailed level: we recommend that you create an Event process only for those events that impact the delivery of a service. You can include information and warning alerts, but consider if this provides too much noise before you implement this.

The URL or batch file / command line from your monitoring tool can contain many attributes that populate the initial Event process. These typically include the Event Source, Event Type, CI, and Title. However, you can map many other attributes, such as a Priority and/or Response Level to provide you with escalation activities (color changes, e-mail notification, reassignment, and so on).

Linking CIs to Services

If you link your monitored CIs to the Services in the Service Desk CMDB, you can create a query on the CI relationship table, linked to the Event processes to see where CIs are recorded on active Events, and also see the Service that is affected/connected to the CI on the Event. With these relationships in place, you can run an Impact Analysis from an Event processes.

Auditing Events

All process actions are available to Event Manager – not only Create / Add Note / Resolve and Close. You can create and use custom actions to use with Event Manager that are based on the type of alert or notification that your external system can generate. These actions are recorded and audited like any other actions, so by associating an Event Manager system user with the Event Manager service, you can identify which process actions resulted from external systems monitored by Event Manager.

Notifications

Notification is the same as with any process. In your default Event process, always include an assignment with relevant notifications. Also include escalations using Response Levels to provide many other notification options.

Create a Current Events query

Add a Current Events query to Incident Management dashboards to enable Incident Management staff to see, in real time, where current Service delivery may be impacted. If you are using Self Service, you could present this information to your end-users graphically (perhaps like traffic lights) for the key business Services. When an Event process is created, set the status on the CI or Service to Impacted, and present the relevant image from the Status on the dashboard.

Automatic and manual actions

When developing your Event process designs, remember that an Event may involve both automatic and manual interactions. You may not want everything to be automated, but instead to use analysts to validate certain steps.

For example, you can configure Event Manager to create an Event process that automatically appears on an Event Management dashboard, and is automatically escalated to notify an analyst. The analyst then reviews the Event and decides whether to mark the affected Services as impacted, and whether to generate a linked Incident from the Event. All of the standard process-linking abilities remain, so you can create a Major Incident, generate a Change, and link an Event to a Change within your process design.

Automated recovery

You could create an Event process in Service Desk that includes all of the required ITSM notifications and escalations. However, you can configure the Ivanti Automation to perform a recovery action when it detects the event (everything from a rebooting to starting a new virtual environment). When the monitoring tool detects that the device/service has recovered, it updates Event Manager, which then closes the Event process. All of the availability statistics for the Service are captured, but the downtime is minimized.

Reporting on Event Management

When you are automatically creating and resolving Event processes, you can produce some powerful reporting and information outputs.

While you are creating Events for system-down type occurrences, you are automatically recording the downtime and uptime of a CI and potentially also the service it is attached to. You can amend the Mean Time Between Failure reports supplied with Service Desk to report on this information.

A graph of Events over Time for one or more Services is a powerful input into Problem Management, providing awareness of any increased rate of events outside of the system monitoring team.

Event Manager mappings

Event Manager provides mapping of fields from incoming events to new processes. For details of how to set this up, see Configuring Event Manager. Typically you will map the Event Description, Configuration Item, Priority and the date time that the Event process was created.

To map these fields follow the instructions described in Mapping event attributes to process attributes, but make sure that you link the inbound Event Description to the Description attribute on the Event process. Do the same for the Configuration Item and the Priority if one is provided. You do not need to create a mapping for the Creation date and time, because this is set automatically.

Using the Service Level Agreement Rules enables you to set the Response Level automatically from the Priority or any other values on the Event. This means that the escalations and notifications from alerts can vary based on the Event's priority.

If you want lower priority Events to be routed and progressed differently from high priority or critical Events, modify the process to include decisions and branching based on the Priority. Create a decision on the process, and drag the actions you require onto each path out of the decision. Alternatively, create three different Network Event Sources for different levels of alert, and configure each to launch a totally different process.

Design idea: it is easier to manage a single Event process with branches than to maintain several similar processes.

Any process action can be performed through Event Manager alerts. However, there may be some that you will always need in addition to creating new Event processes: for example, Resolution or Closure.

To Close or Resolve event processes from alerts automatically:

  1. Set up your Event as usual.

    2. For more information, see Configuring the Network Event Source.

  2. Select the action Close or Resolve as appropriate.
  3. Complete the mappings.
    Usually you map only Event Description to the Description on the Closure or Resolution.
  4. Create a suitable event definition.
    Usually you specify that an Event with Type of Close performs the Close action set above.

You may want some actions to run automatically, based on the Type or Priority of the Event. For example, if a Priority 1 event always needs a linked incident to be created (for example with a Major Incident), then you can use the process branching described above. On the high priority branch of your process design, add a Create Incident automatic action with related attribute values, so the name of the CI, Service or Description is automatically copied onto the linked Incident. You can also set default values on this automatic action to preset values on the new Incident.

The same creation behavior applies for Changes. Although you can manually create a Change from an Event, you could automatically create, populate and link a Change in Process Designer in the same way as described above.

Handling different Event types

Monitoring tools provide many different types of alert. Within Service Desk you can split different alert types into different Event processes to ensure the appropriate behavior. Use the EventType passed in from the alert to route the Event process through different branches – to create a major Incident from a failure, for example, or to provide notification-only warnings and no action for information. Create a Decision in Process Designer for Is Event Type = Information and Is event Type = Warning to route down the correct Event path.

Alternatively, you can have different alert types initiating totally different processes. Typical alert types include Information, Warning and Exception, which you can set manually on the Event window.

To trap and process Information, Warning and Exception alerts as separate processes:

  1. Create a default Event Type called DeviceDown.
  2. Follow the guidelines in Configuring the Network Event Source to create new event sources for the Event Types DeviceWarning and DeviceInformation, (and possibly DeviceException if this is different from DeviceDown in your organization).
  3. Map each EventType to the relevant Event Process to provide the behavior required from different types of event.

Design Idea: Don't bring too many alerts into Event Management. Your monitoring tools serve a purpose, and bringing every information message and warning into Service Desk processes may be unnecessary. You can use browser controls on dashboards and windows (in Console) to display web content, so you can often display your monitoring tool's full set of alert and notification types directly in this way, inside the Service Desk interface.